home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000161_misckit-reques…aska.et.byu.edu_Fri Apr 1 17:13 MST 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  7KB
  1. Received: from acs1.byu.edu by alaska.et.byu.edu; Fri, 1 Apr 1994 17:13:32 -0700
  2. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-7 #4169)
  3.  id <01HAO2NYAXC0IA0CWZ@yvax.byu.edu>; Fri, 1 Apr 1994 17:12:04 MST
  4. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-7 #4169)
  5.  id <01HAO2N15MJKQPFT4Z@yvax.byu.edu>; Fri, 1 Apr 1994 17:11:18 MST
  6. Received: from acs1.byu.edu by alaska.et.byu.edu; Fri, 1 Apr 1994 17:07:59 -0700
  7. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-7 #4169)
  8.  id <01HAO2HWHLKGIA0CWZ@yvax.byu.edu>; Fri, 1 Apr 1994 17:07:11 MST
  9. Received: from sonata.cc.purdue.edu by yvax.byu.edu (PMDF V4.3-7 #4169)
  10.  id <01HAO2GTLJMOQPFR5L@yvax.byu.edu>; Fri, 1 Apr 1994 17:06:18 MST
  11. Received: from toccata.cc.purdue.edu by sonata.cc.purdue.edu
  12.  (NX5.67e/Purdue_CC) id AA22774; Fri, 1 Apr 94 19:06:08 -0500
  13. Received: by toccata.cc.purdue.edu (NX5.67e/NX3.0X) id AA04810; Fri,
  14.  1 Apr 94 19:06:05 -0500
  15. Received: by NeXT.Mailer (1.95)
  16. Received: by NeXT Mailer (1.95)
  17. Date: Fri, 01 Apr 1994 19:06:05 -0500
  18. From: kane@sonata.cc.purdue.edu (Christopher Kane)
  19. Subject: The birth of a notion: MiscAgent
  20. To: misckit@byu.edu
  21. Reply-to: kane@cs.purdue.edu
  22. Message-id: <9404020006.AA22774@sonata.cc.purdue.edu>
  23. Content-transfer-encoding: 7BIT
  24. Status: RO
  25.  
  26. Don suggested there were probably people on the list who would be
  27. interested in this message I had sent to him...
  28.  
  29. -----begin message----
  30.  
  31. Don't think about *HOW* this would be done, just think about the
  32. possibility...
  33.  
  34. Premise: the development of classes like MiscRegistration,
  35. MiscInfoController, and indeed many classes and categories, is to
  36. provide the developer with a mechanism to achieve common goals/features
  37. in an application that is as close to "plug-n-play" as possible,
  38. alleviating the developer from doing the work.
  39.  
  40. Premise: the responder chain is a powerful user-interface mechanism
  41. allowing users to send messages to application objects (via mouse
  42. or keyboard).
  43.  
  44. Premise: developers would like a (mostly) automated, lazy, mechanism
  45. for handling the loading of .nib files, loading of dynamically
  46. loaded classes, and user-interface messages (such as those generated
  47. from the application's menu).
  48.  
  49. Premise: that it would be possible, using the responder chain and
  50. message forwarding mechanisms to build a class which 1) intercepted
  51. messages of unknown destination on the responder chain, and forwarded
  52. them to the appropriate class (loading the class first if necessary),
  53. and 2) had mechanisms for limiting itself and subclasses to only
  54. one instance (as many objects in the AppKit do).  This class would
  55. be a manager of classes; subclasses would be managers of other
  56. classes, managers of .nib files (e.g., panels), managers of instances,
  57. or managers of other things (who knows?).
  58.  
  59. "Conclusion": MiscAgent
  60.  
  61.  
  62. A possible picture:
  63.            Responder
  64.            |
  65.            MiscAgent
  66.   ...---+----------+------------------+---...
  67. MiscInfoMenuAgent                MiscNibAgent
  68.             +-----------------+--------------+-----...
  69.       MiscInfoPanelAgent   MiscOrderFormAgent   etc...
  70.  
  71. MiscNibAgent = MiscNibController +- a few things
  72.  
  73.  
  74. Scenario #1: Charles, a developer, has the task of writing a news
  75. reader application, as much as practical of which will be dynamically
  76. loaded on demand.  There are about half-a-dozen windows and panels
  77. that he needs to create and manage, the main menu which will have
  78. over 50 "leaf" menu items, a few specialized user-interface
  79. controls/views, several custom objects to handle news-related
  80. things, and many internal objects/categories to dynamically load
  81. classes, .nib files, and perform clerical work of the application.
  82. After planning his "attack" on the task, he adds the MiscAgent
  83. class to his project, creates the panel nib files, creates a small
  84. specialized subclass (of MiscNibAgent) for each panel, sets up the
  85. main menu, connecting most of the menu cells to the first responder
  86. (the connection is necessary to specify the action, unfortunately,
  87. within IB), compiles the application and runs it to test much of
  88. the interface.  The panels pop up when the appropriate menu items
  89. are clicked on.  Since the classes control the panels, the classes
  90. must have been loaded correctly (as well as the panels).  Charles
  91. doesn't know how this is happening--he doesn't care--as long as it
  92. works.
  93.  
  94. Scenario #2: (a message odyssey) The user Barbara runs Charles'
  95. application, and eventually clicks on the Info/Info Panel... menu
  96. item.  This menu item has no target, but it does have an action
  97. (-orderFrontInfoPanel:).  The AppKit responder chain message dispatch
  98. engine goes to work first looking for a responder in the key window,
  99. then the main window (if different), but none of those objects
  100. implement the action message.  The message finally is attempted to
  101. be sent to the MiscAgent instance (how is not important right now),
  102. which accepts the message.  It then goes to work looking for a
  103. class/instance that implements the message.  Hmmm, the MiscInfoPanelAgent
  104. has a method by that name.  Hmmm, that class isn't loaded yet.
  105. Let's load it, initialize it.  Ok, send it the message.  The newly
  106. loaded class has .nib file loaded (via a method inherited from
  107. MiscNibAgent) and displays it, and manages some animation.  Barbara
  108. sees the panel appear on the screen, with animation running.  When
  109. she leaves the Info Panel on-screen, and clicks on another window
  110. (in the app) to work in it, the animation stops.  The MiscInfoPanelAgent
  111. has been made the delegate of the window, and is toggling the animation
  112. in response to -windowDidBecomeKey and -windowWillBecomeKey methods.
  113.  
  114.  
  115. I think this is a two/three/eight person project to do it well.
  116. One key point, is that the responder chain becomes used by
  117. classes which are not using it now.  Another is that this is, in
  118. many ways, quite an abstract class (though in a different way than
  119. that term is meant with Object or Responder or Cell).
  120.  
  121. The two key difficulties are, 1) how does the MiscAgent "hook into"
  122. the responder chain.  There is no convenient mechanism (except the
  123. NXApp's delegate, and I'd hate to "take" that) provided by the
  124. AppKit.  I can think of a mechanism or two, but I don't like that
  125. sensation of my hair standing on end. :)  And, 2) how does the object
  126. know which classes implement which methods before loading.  One way
  127. would be a configuration file (the type of thing Opener.app has for
  128. archive formats, for example).  This file could be generated
  129. automatically with an auxiliary tool at make time, and would reside
  130. in the app wrapper.  Other mechanisms may exist.
  131.  
  132.  
  133. Sound interesting?
  134.  
  135. Christopher Kane
  136.